Bumped revision number for anything that depends_on "ruby", so as to trigger rebuild

Can you revert this? Not everything has to be rebuilt, only things that link to ruby libraries might need a rebuilt.

Bumped revision number for anything that depends_on "ruby", so as to trigger rebuild

Can you revert this? Not everything has to be rebuilt, only things that link to ruby libraries might need a rebuilt.

My latest push is just Ruby and its Aliases, backing out (squashed) the bumps to all the other formula. Unfortunately it looks like in doing so I may have broken a fix @crunchtime-ali added for k9s right before I pushed the squashed commit.

My latest push is just Ruby and its Aliases, backing out (squashed) the bumps to all the other formula. Unfortunately it looks like in doing so I may have broken a fix @crunchtime-ali added for k9s right before I pushed the squashed commit.

This k9s break looks like merge noise, which came out of the PR when I rebased to clean it up and pick up 981c7ec.

Why bump the revisions again? I really doubt that would be needed for most of the formulae in the list

Why bump the revisions again? I really doubt that would be needed for most of the formulae in the list

Most of the formulae that depends_on "ruby" actively depend on the specific version of Ruby that was extant at build time, which shows up as a large number of linkage failures in CI. The revision bumps update that version expectation to Ruby 3.3.

I'd initially done a blanket rebuild in the initial PR. The new bumps are more considered, and only for formulae that failed to build in CI because of the version mismatch:

• For all but weechat, the dependent formulae link to the version of libruby available in /opt/homebrew/opt/ruby/lib/ at build time: formerly libruby.3.2 but now libruby.3.3 (.dylib on macOS). You can see these failures in the unfortunate number checks I triggered to get here, e.g. https://github.com/Homebrew/homebrew-core/actions/runs/7322797920/job/19944994270#step:3:1341

• wechat declares a list of Ruby versions to work with, so for that formula I added a line to add Ruby 3.3 to the list if the list doesn't yet include Ruby 3.3.

Most of the formulae that depends_on "ruby" actively depend on the specific version of Ruby that was extant at build time, which shows up as a large number of linkage failures in CI. The revision bumps update that version expectation to Ruby 3.3.

We had a similar need in Ruby 3.2, and Ruby 3.1. I expect we also had them in prior major version bumps but I haven't tracked down all the PRs.

I'm somewhat at a loss on these remaining failing checks. For solargraph I could explicitly declare an xz dependency, but that's purely speculative since it should work as-is.

• wechat declares a list of Ruby versions to work with, so for that formula I added a line to add Ruby 3.3 to the list if the list doesn't yet include Ruby 3.3.

FWIW I also put up weechat/weechat#2055 to update Weechat's own build system to detect the new Ruby version. If they take it then this patch here should still work: we'll still need the rebuild, and the install version check replacement should noop.

I'm somewhat at a loss on these remaining failing checks. For solargraph I could explicitly declare an xz dependency, but that's purely speculative since it should work as-is.

Explicitly declaring the xz dependency got rid of that particular failure.

It looks like the Intel tests are reliably timing out at around 1:30. Given that the remainder seems to be passing, would it make sense to land the PR as-is, and then fix any breakage we find afterwards? Or to remove the dependents from the PR, land the newRuby, and then follow up with PRs to fix dependents?

Thanks again @faisal, great work here!